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ABSTRACT 

We extend previous dependence-based representations called 
system dependence graphs (SDGs) to represent aspect-oriented 
programs and present an SDG construction algorithm. This 
algorithm first constructs a module dependence graph (MDG) 
for each piece of advice, introduction, and method in aspects 
and classes. It then uses existing techniques to connect the 
MDGs at call sites to form a partial SDG. Finally, it weaves 
the MDG for each piece of advice into the partial SDG for 
those methods whose behavior may be affected by the ad- 
vice. The result is the complete SDG. Our SDGs capture 
the additional structure present in many aspect-oriented fea- 
tures such as join points, advice, introduction, aspects, and 
aspect inheritance, and various types of interactions between 
aspects and classes. They also correctly reflect the semantics 
of aspect-oriented concepts such as advice precedence, intro- 
duction scope, and aspect weaving. SDGs therefore provide 
a solid foundation for the further analysis of aspect-oriented 
programs. 

1. INTRODUCTION 

The program, dependence graph (PDG) effectively supports 
powerful program analysis by explicitly capturing depen- 
dence information between different program elements [6]. 
Although originally proposed for compiler optimizations, the 
PDG has also been used as an effective foundation for vari- 
ous software engineering tasks such as program understand- 
ing, debugging, testing, and maintenance [3, 16, 17]. PDGs 
were originally constructed for procedural programs [6, 7], 
and have been recently extended to support various object- 
oriented features such as classes and objects, inheritance, 
polymorphism, and dynamic binding [11, 13, 14, 15]. 

Aspect-oriented programming (AOP) [8, 19] is a new lan- 
guage paradigm proposed for cleanly modularizing the cross- 
cutting structure of concerns such as exception handling, 
synchronization, and resource sharing. Expressing such cross- 
cutting concerns using standard language constructs usually 
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produces tangled, poorly structured code. AOP can control 
such code tangling, improving the structure of the program 
and making it easier to develop and maintain. 

Aspect-oriented languages present unique opportunities and 
problems for program representation schemes. To enable 
the development of effective analysis for aspect-oriented pro- 
grams, the program representation scheme must appropri- 
ately preserve the structure associated with the use of fea- 
tures such as joint points, advice, and introduction. It is 
therefore of interest to develop appropriate program repre- 
sentations for aspect-oriented programs. 

Although researchers have developed many representations 
for procedural and object-oriented programs, little work has 
been carried out on representations that preserve the struc- 
ture of aspect-oriented programs. Due to some specific aspect- 
oriented features presented in recent AOP languages, exist- 
ing representations for procedural and object-oriented pro- 
grams can not be used directly for aspect-oriented programs. 

In this paper we extend previous dependence-based repre- 
sentations called system dependence graphs (SDGs) to rep- 
resent aspect-oriented programs and present an SDG con- 
struction algorithm. This algorithm first constructs a mod- 
ule dependence graph (MDG) for each piece of advice, in- 
troduction, and method in aspects and classes. It then uses 
existing techniques to connect the MDGs at call sites to form 
a partial SDG. Finally, it weaves the MDG for each piece of 
advice into the partial SDG for those methods whose behav- 
ior may be affected by the advice. The result is the complete 
SDG. Our SDGs capture the additional structure present in 
many aspect-oriented features such as join points, advice, 
introduction, aspects, and aspect inheritance, and various 
types of interactions between aspects and classes. They also 
correctly reflect the semantics of aspect-oriented concepts 
such as advice precedence, introduction scope, and aspect 
weaving. SDGs therefore provide a solid foundation for the 
further analysis of aspect-oriented programs. One key point 
for representing aspect weaving is to determine, for each 
pointcut pc, a set of methods in classes that might be af- 
fected by pc. Based on this kind of information, we can 
weave the MDGs for advice into the partial SDG for base 
code in a natural way. 

Our main contribution in this paper is a new representation 
for aspect-oriented programs. This representation can serve 
as an effective foundation for program analysis. Because the 
representation preserves the additional structure present in 



ceO public class Point { 

si protected int x, y; 
me2 public Point (int xl, int yl) { 

s3 X = xl; 

s4 y = yl; 

meS public int getX() { 
s6 return x; 

me? public int getY() { 
s8 return y; 

me9 public void setX(int _x) { 
slO X = _x; 

mell public void setY(int _y) { 
sl2 y = _y; 

inel3 public void printPosition () { 
sl4 System.out.println ("Point at ( "+x+" , "+y+") ") ; 

melS public static void main (String [] args) { 

sl6 Point p = new Point (1,1); 

sl7 p.setX(2); 

sl8 p.setY(2); 

>^ 

cel9 class Shadow { 
s20 public static final int offset = 10; 
s21 public int x, y; 

me22 Shadow (int x, int y) { 

s23 this.x = x; 

s24 this.y = y; 
ine25 public void printPosition () { 

s2 6 System. outprintln ("Shadow at 
( " +X+ " , " +y+ " ) " ) ; 

>^ 

(a) 



ase27 aspect PointShadowProtocol { 
s2 8 private int shadowCount = 0; 
me29 public static int getShadowCount () 
s3 return PointShadowProtocol. 

aspectOf .shadowCount; 
} 
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me32 

s33 

me34 
s35 



p36 
p37 



p38 



s40 
s41 
s42 

ae43 
s44 
s45 
s46 
s47 

ae48 
s49 
s50 
s51 
s52 



private Shadow Point . shadow; 
public static void associate (Point p. Shadow s) { 
p . shadow = s ; 



} 

public static Shadow getShadow (Point 

return p. shadow; 
} 



P) { 



pointcut setting (int x, int y. Point p) : 
args(x,y) && call (Point .new (int, int) ) ; 

pointcut settingX (Point p) : 

target (p) && call (void Point . setX (int) ) ; 

pointcut settingY (Point p) : 

target (p) && call (void Point . setY (int) ) ; 

after (int x, int y. Point p) returning : 
setting (x, y, p) { 
Shadow s = new Shadow(x,y); 
associate (p, s) ; 
shadowCount++ ; 

after (Point p) : settingX (p) { 
Shadow s = new getShadow (p) ; 
s.x = p.getXO + Shadow.of f set; 
p. printPosition ; 
s .printPosition ; 

after (Point p) : settingY (p) { 
Shadow s = getShadow (p) ; 
s.y = p.getYO + Shadow.of f set; 
p. printPosition ; 
s .printPosition ; 

(b) 



} 



Figure 1: An Aspect J program which contains (a) base code and (b) aspect code. 



the aspect-oriented program, it is especially appropriate for 
developing software engineering tools. 

The rest of the paper is organized as follows. Section 2 
briefly introduces the system dependence graph for standard 
object-oriented programs and presents the aspect-oriented 
programming language Aspect J. Section 3 presents the SDG 
for aspect-oriented programs and the construction algorithm 
for an SDG. Section 4 discusses some related work; we con- 
clude in Section 5. 

2. BACKGROUND 

We next briefly introduce the Aspect J language and the sys- 
tem dependence graphs for object-oriented programs. 

2.1 Aspect-Oriented Programming with As- 
pectj 

We present our extended SDG in the context of Aspect J, the 
most widely used aspect-oriented programming language. 
[9]. Our basic techniques, however, deal with the basic con- 
cepts of aspect-oriented programming and therefore apply 
to the general class of AOP languages. 

AspectJ [9] is a seamless aspect-oriented extension to Java; 
AspectJ adds some new concepts and associated constructs 
to Java. These concepts and associated constructs are called 
join points, pointcut, advice, introduction, and aspect. We 
briefly introduce each of these constructs as follows. 

The aspect is the modular unit of crosscutting implemen- 
tation in AspectJ. Each aspect encapsulates functionality 
that crosscuts other classes in a program. Like a class. 



an aspect can be instantiated, can contain state and meth- 
ods, and also may be specialized with subaspects. An as- 
pect is combined with the classes it crosscuts according to 
specifications given within the aspect. Moreover, an aspect 
can use an introduction construct to introduce methods, 
attributes, and interface implementation declarations into 
classes. Introduced members may be made visible to all 
classes and aspects (public introduction) or only within the 
aspect (private introduction), allowing one to avoid name 
conflicts with pre-existing elements. For example, the as- 
pect PointShadowProtocol in Figure 1 privately introduces 
a field shadow to the class Point at s31. 

A central concept in the composition of an aspect with other 
classes is called a join point. A join point is a well-defined 
point in the execution of a program, such as a call to a 
method, an access to an attribute, an object initialization, 
an exception handler, etc. Sets of join points may be rep- 
resented by pointcuts^ implying that such sets may crosscut 
the system. Pointcuts can be composed and new pointcut 
designators can be defined according to these combinations. 
AspectJ provides various pointcut designators that may be 
combined through logical operators to build up complete de- 
scriptions of pointcuts of interest. For example, the aspect 
PointShadowProtocol in Figure 1 declares three pointcuts 
named setting, settingX, and settingY at p36, p37, and 
p38. 

An aspect can specify advice^ which is used to define code 
that executes when a pointcut is reached. Advice is a method- 
like mechanism which consists of instructions that execute 
before^ after ^ or around a pointcut. around advice executes 
in place of the indicated pointcut, allowing a method to be 
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SDG for the base code of program in Fig- 



replaced. For example, the aspect PointShadowProtocol in 
Figure 1 declares three pieces of after advice at ae39, ae43, 
and ae48; each is attached to the corresponding pointcut 
setting, settingX, or settingY. 

An AspectJ program can be divided into two parts: base 
code which includes classes, interfaces, and other standard 
Java constructs and aspect code which implements the cross- 
cutting concerns in the program. For example. Figure 1 
shows an AspectJ program that associates shadow points 
with every Point object. The program can be divided into 
the base code containing the classes Point and Shadow, and 
the aspect code which has the aspect PointShadowProtocol 
that stores a shadow object in every Point. Moreover, the 
AspectJ implementation ensures that the aspect and base 
code run together in a properly coordinated fashion. The 
key component is the aspect weaver, when ensures that ap- 
plicable advice runs at the appropriate join points. For more 
information about AspectJ, refer to [2]. 

To focus on the key ideas of our work, we do not discuss 
how to represent standard constructs such as classes and in- 
terfaces in this paper because they can be represented using 
existing techniques [13, 14]. To simplify the presentation we 
present only those join points related to method and con- 
structor calls. 

2.2 System Dependence Graphs for Object- 
Oriented Programs 

The system dependence graph (SDG) [13, 14] for an object- 
oriented program is a collection of method dependence graphs; 
each of which represents a mainO method or a method in 
a class of the program. Additional arcs represent direct or 



indirect dependences between a call site and the invoked 
method and transitive interprocedural data dependences. A 
method dependence graph (MDG) for a method ?7i is a di- 
rected graph^ whose vertices represent statements or predi- 
cate expressions in m] arcs represent control and data depen- 
dences. The MDG also has a unique vertex called method 
entry vertex to represent the entry into m. 

Formal parameter vertices are used to model parameter pass- 
ing between methods. There is a formal-in vertex for each 
formal parameter of the method and a form^al-out vertex for 
each formal parameter that may be modified by the method. 
Each call site has an associated call vertex and actual param- 
eter vertices: an actual-in vertex for each actual parameter 
and an actual- out vertex for each actual parameter that may 
be modified by the called method. In addition, each formal 
parameter vertex is control dependent on the method entry 
vertex, and each actual parameter vertex is control depen- 
dent on the call vertex. 

The construction of the standard SDG can be performed 
by connecting MDGs at call sites. A call arc is used to 
connect the call vertex and the entry vertex of the called 
method's MDG. Actual-in and formal-in vertices are con- 
nected by parameter-in arcs and formal-out and actual-out 
vertices are connected by param^eter-out arcs. These param- 
eter arcs represent parameter passing. Moreover, to repre- 
sent the transitive flow of dependences in the SDG, sum^m^ary 
arcs [7] are created by connecting an actual-in vertex to an 
actual-out vertex if the value associated with the actual-in 
vertex affects the value associated with the actual-out ver- 
tex. 

Existing SDGs for object-oriented programs can also rep- 
resent object-oriented features such as classes and objects, 
class extensions, interfaces and their extensions, polymor- 
phism, object parameters, and class libraries; details can be 
found in [11, 13, 14]. 

[Example] Figure 2 shows the SDG for the base code of the 
program in Figure 1, especially a part of class Point. In the 
figure, circles represent program statements and are labeled 
by statement numbers. Ellipses represent parameter ver- 
tices and are labeled with /z_m or fijDut for formal param- 
eters and ai-in or aijout for actual parameters. Following 
Larsen[13] we refer to a particular parameter vertex by pre- 
fixing the parameter label with the call or entry vertex upon 
which it is control dependent. For example, sl7->a3_in 
refers to the parameter vertex representing the actual pa- 
rameter "_x_in=2" in the call to setXO at sl7. In the 
figure, we use different types of arcs to represent control de- 
pendences, data dependences, method calls, and parameter 
bindings. For example, there are control dependences arcs 
(sl7, a3_in) and (me9, f l_in) since a3_in is an actual-in 
vertex attached to a method call to setXO at sl7 and f l_in 
is a formal-in vertex attached to the method entry vertex 
me 9. p is defined in sl6 and used in sl7 and sl8. Therefore, 
there are data dependence arcs (sl6, sl7) and (sl6, sl8). 
A parameter binding occurs at the call to setYO at sl8 be- 
tween 2 in mainO and _y in setY() . This parameter binding 
leads to a parameter-in arc (sl8->a4_in, mll->f4_in) and 
a parameter-out arc (mll->f 2_out, sl8->a6_out). Finally, 



A directed graph G = (V, A), where V is a set of vertices and A G 
y X y is a set of arcs. Each arc (v, v') G A is directed from v to v'; 
we say that v is the source and v' the target of the arc. 



there is a summary arc (sl6->al_in, sl6->a5_out) to repre- 
sent the fact that in Point () constructor, the value of 1 that 
is passed to Point () affects the value of x that is returned 
by Point (). 

3. SYSTEM DEPENDENCE GRAPHS FOR 
ASPECT-ORIENTED PROGRAMS 

We next present our system dependence graphs for aspect- 
oriented programs and our system dependence graph con- 
struction algorithm. We also discuss the representation of 
aspects, aspect and class interaction, and a complete aspect- 
oriented program using our representation. 

3.1 Advice, Introduction, Pointcuts and 
Methods 

In addition to methods, an aspect may contain other mod- 
ular units such as advice and introduction. Since advice 
and introduction can be regarded as method-like units, we 
can also represent each piece of advice or introduction by 
a method dependence graph (MDG) as described in Section 
2.2. To keep our terminology consistent in the rest of paper, 
we use the word "module" to stand for a piece of advice, a 
piece of introduction, or a method in an aspect and also a 
method in a class, and use a module dependence graph to 
represent it. 

A module dependence graph (MDG) for a module m, denoted 
by Gmdg, is a directed graph {e,V,A) where e is an entry 
vertex to represent the entry into m] V = VnUVc such that 
Vn is a set of normal vertices and Vc is a set of call vertices; 
A = Acon^Adat such that Aeon is a set of control dependence 
arcs such that any (it, v) G Aeon iff u is control-dependent 
on V ; Adat is a set of data dependence arcs such that any 
(it, v) G Adat iff u is data- dependent on v . 

Gmdg is similar to the procedure dependence graph defined 
in [7] for representing a procedure in a procedural program. 
A vertex is called a normal vertex if it represents a statement 
or predicate expression in m without containing a call or 
object creation. Otherwise it is called a call vertex. Gmdg 
consists of two types of arcs, i.e., control dependence arcs 
and data dependence arcs. Let u and v be two statements in 
m, informally u is directly control- dependent on v if whether 
u is executed or not is directly determined by the evaluation 
result of V, and u is directly data- dependent on v if the value 
of a variable computed at v has a direct infiuence on the 
value of a variable computed at u. 

For a piece of before, after, or around advice a, we use an 
MDG to represent a; the MDG has a unique entry vertex to 
represent the entry into a. To represent a piece of introduc- 
tion^ two cases should be considered. If a piece of introduc- 
tion i introduces a method (or constructor) into a class, we 
use the MDG to represent z; the MDG has a unique entry 
vertex to represent the entry into i. If a piece of introduc- 
tion i introduces a field / to a class, we need not construct 
the MDG for i. In such a case, we regarded / as an aspect 
instance variable (we discuss this issue in Section 3.2). For a 
pointcut pc, since it has no body code, we use a vertex called 
join-point vertex to represent pc; it also represents the entry 
into pc. 

3.2 Base and Extended Aspects 



We discuss how to use aspect dependence graphs to repre- 
sent a base or extended aspect^. 

Base Aspects. To facilitate the analysis of an individual 
aspect, we represent each aspect in an aspect-oriented pro- 
gram by an aspect dependence graph. 

Let a be an aspect with k modules {mi\i = 1, 2, ..., k.} and 
Gi = (ci^Vi^Ai) be the MDG for module rrii. An aspect 
dependence graph (ADG) for a, denoted by Gadg, is a di- 
rected graph (e", ^", V",^"), where e" is the aspect entry 
vertex; S^ = U^^ie^ is the set of entry vertices of the mod- 
ules in a. V" = U^=iVi U F/^ U V^e U l^/o U Kl U IC such that 
^i=iVi is the set of vertices; each represents a statement or 
control predicate in the modules in a; Vpe is the set oi join- 
point vertices; Vfl or Vf^ is the set oi formal-in or formal- out 
vertices; Vai or Vao is the set of actual-in or actual- out ver- 
tices. A" = uf=iAi U A^, U A^i U A% U A^cupA^ U A? such 
that Ui=iAi is the set of control dependence arcs and data 
dependence arcs in the MDGs of modules in a; A^s is the 
set of m^em^hership arcs; Api or Apo is the set oi param^eter-in 
or parameter- out arcs; Ac is a set of call arcs; A^ is the set 
of pointing arcs; A^ is a set of sum^m^ary arcs. 

Gadg is a collection of MDGs; each represents a piece of ad- 
vice, a piece of introduction, or a method in a. The aspect 
entry vertex represents the entry into a. An aspect member- 
ship arc represents the membership relationships between a 
and its members (advice, introduction, pointcuts, or meth- 
ods) by connecting a's entry vertex to the entry vertex of 
each member. A join-point vertex represents a pointcut in 
a. Formal-in and formal-out vertices represent formal pa- 
rameters in a module m; there is a formal-in vertex for each 
formal parameter of m and a formal-out vertex for each for- 
mal parameter that may be modified by m. Actual-in and 
actual-out vertices are used to represent actual parameters 
at each call site in a module m; there is an actual-in vertex 
for each actual parameter of m and an actual-out vertex for 
each actual parameter that may be modified by m. Each 
actual-in or actual-out vertex is control dependent on its 
corresponding call vertex and each formal-in or formal-out 
vertex is control dependent on the entry vertex. 

A call arc represents the calling relationship^ between two 
modules mi and m2 in a by connecting the call vertex in 
mi to the entry vertex of m2's MDG if there is a call in 
mi's body to call m2. A parameter-in or parameter- out arc 
represents the parameter passing between modules mi and 
m2 in a by connecting an actual-in and a formal-in vertex to 
form a parameter-in arc, and a formal-out to an actual-out 
vertex to form a parameter-out arc if there is a call in mis 
body to call m2. A summary arc models the transitive fiow 
of dependence across a module call within a, as introduced 
in Section 2.2. 

Consider an aspect instance variable /in a. Since the vari- 
able is accessible to all modules in a, we create a formal-in 
or formal-out vertex for each module in a that references /. 

Finally, for each pointcut pc in a, we connect the aspect 



We can use an existing technique [13] to represent a base and ex- 
tended class. 

Since advice in AspectJ is automatically woven into some method(s) 
by a compiler (called ajc) during aspect weaving process, there exists 
no call to the advice. As a result, there exists no call from introduc- 
tion (or method) to advice. 
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Figure 3: An ADG for aspect Point ShadowProtocol in Figure 1. 



entry vertex to pc's join-point vertex through an aspect 
membership arc, and also pc's join-point vertex to the en- 
try vertex of its corresponding advice by a pointing arc to 
represent the relationship between them. Since there exists 
parameter passing between pc and its corresponding advice 
a, parameter-in and parameter-out arcs are created to con- 
nect an actual-in vertex to a formal-in vertex, and also a 
formal-out vertex to an actual-out vertex between pc and a. 

[Example] Figure 3 shows the aspect dependence graph for 
aspect PointShadow Protocol. The rectangle represents the 
aspect entry vertex and is labeled by the statement label as- 
sociated with the aspect entry. Circles represents statements 
and are labeled with the corresponding statement number 
in the aspect. For example, ase27 is an aspect entry ver- 
tex; ae39, ae43, and ae48 are advice entry vertices; me29, 
me32, and me34 are method entry vertices, p36, p37, and 
p38 are join-point vertices. (ase27, ae39), (ase27, me32), 
and (ase27, pe36) are aspect membership arcs. Each entry 
vertex is the root of a sub-graph which is itself a partial 
SDG. Each sub-graph may contain control and data depen- 
dences, call and parameter, pointing, and summary arcs. 
(p36,ae39), (p37,ae43), and (p38,ae48) are pointing arcs 
that represent interactions between pointcuts and their cor- 
responding advice. To represent parameter passing between 
pointcut p36 and its corresponding after-returning advice, 
formal-in and formal-out vertices are created for the for- 
mal parameters x, y, and p of the advice, and actual-in and 
actual-out vertices are created for the parameters x, y, and p 
of pointcut setting. Also parameter-in and parameter-out 
arcs are created to connect these formal and actual vertices. 



Extended Aspects. An aspect can extend an abstract as- 
pect^, a class, and can implement any number of interfaces. 
The ADG should be able to represent an extended aspect. 
Given an abstract aspect a and an aspect a that extends 
a, we can construct the ADG for a' as follows. We first con- 
struct the MDG for each module m in a' , and then reuse 
the MDGs of all modules that are inherited from a. There 
is an entry vertex for a to represent the entry into a, and 
aspect-membership arcs are used to connect the aspect entry 
vertex to the entry vertex of each modules in a. The aspect- 
membership arcs are also used to connect the aspect entry 
vertex to the entry vertices of any module in a that are in- 
herited by a . We also use formal-in and formal-out vertices 
to model the parameter passing in a and instance variables 
in a and a that may be referenced by a call to this mod- 
ule. Similarly, formal-out vertices for a module represent the 
module's formal parameters and instance variables in super 
or extended aspects that may be modified by a call to this 
module. Similarly, we can represent an aspect that extends 
a class or implements an interface using existing techniques 
originally developed for object-oriented programs [11, 13]. 

3.3 Interactions between Aspects and Classes 

An aspect can interact with a class in several ways: by ob- 
ject creation, method call, introduction declaration, and join 
point. An SDG should be able to represent these interactions 
between aspects and classes. 

Object Creation. A module m in an aspect a may create 
an object of a class C through a declaration or by using 

In AspectJ, an aspect can not extend a concrete aspect. 



an operator such as new. At this time, there is an impUcit 
call from m to (7's constructor. To represent this implicit 
constructor call, a call arc is added to connect the call vertex 
in a at the site of object creation to the entry vertex e of the 
MDG of (7's constructor. Also, at the call vertex, actual- 
in and actual-out vertices are added to match the formal- 
in and formal-out vertices in the MDG of (7's constructor. 
For example, statement s40 in Figure 1 represents an object 
creation of class Shadow in aspect PointShadowProtocol. To 
represent this object creation, in the SDG of Figure 4, a call 
vertex is created for s40; it is connected to the entry vertex 
me22 of the Point's constructor. Actual-in vertices (a7_in 
and a8_in) and actual-out vertices (alO_out and alO_out) 
for s40 are also added to match the formal-in and formal-out 
vertices for Point's constructor. 

Method Call. An aspect a may have a call from its module 
mi to a method 1712 in the public interface of class C. In 
this case, a call arc is added to connect the call vertex of 
mi to the entry vertex of ?7i2's MDG, and parameter-in and 
parameter-out arcs are added to connect actual-in vertices 
to formal-in vertices, and formal-out vertices to actual-out 
vertices between m.i and m.2- For example, statement s45 in 
Figure 1 represents a call to method getXO of class Point 
in aspect PointShadowProtocol. To represent this method 
call, in the SDG of Figure 4, a call vertex is created for s45; 
it is connected to the entry vertex me5 of method setX(). 
An actual-in vertex (a7_in) for s45 is added to match the 
formal-in vertex for method setX. 

Introduction Declaration. An aspect a may declare a 
piece of introduction i that publicly introduces one method 
(or constructor) into a class C. To represent such an in- 
teraction, the entry vertex of (7's class dependence graph is 
connected to the entry vertex of z's MDG by a class member- 
ship arc because i can potentially affect the type structure of 
C. If a piece of introduction in a publicly introduces a field 
/ into a class (7, we regard / as an instance variable of both 
a and C. Therefore, /is accessible to all modules in a and 
C. In this case, we create a formal-in and formal-out vertex 
for / for each module in a and C in which / is referenced. 
However, if a piece of introduction in a privately introduces 
a field /into a class (7, /is only accessible to all modules in a. 
In this case, we create a formal-in and formal-out vertex for 
/only for each module in a. For example, statement s31 in 
Figure 1 represents a piece of introduction that privately in- 
troduce a field shadow into class Point; this means only code 
defined in PointShadowProtocol can access shadow. To rep- 
resent this introduced field, in the SDG of Figure 4, only a 
formal-in vertex (f 9_in) for shadow is created for method 
getShadowO that references shadow, and both a formal-in 
vertex (f 9_in) and a formal-out vertex (f 9_out) for shadow 
are created for method associate () that modifies shadow. 

Join Point. An aspect may be woven into one or more 
classes at some join points, declared within pointcuts which 
are used in the definition of advice. By carefully examining 
the pointcuts and their associated advice, one can deter- 
mine those methods that a piece of advice may advise. This 
information can be used to connect the base program and 
aspects. Just as an aspect weaves itself into the base pro- 
gram at some join points, we weave the MDGs for advice 
into the partial SDG at join-point vertices (Section 3.5 will 
discuss this issue in detail). For example, the after advice 



declared in aspect PointShadowProtocol (lines ae43-s47) of 
Figure 1 may weave into method setXO of class Point. To 
represent this weaving issue, in the SDG of Figure 4, a weav- 
ing arc (me9, p37) is created to connect the entry vertex me9 
for method setXO to the join-point vertex p37 for pointcut 
settingX. 

3.4 Complete Aspect-Oriented Programs 

We next present a system dependence graph for a complete 
aspect-oriented program. 

Let V be an aspect-oriented program with n modules {m.i\i = 
l,2,...,n.} and d = {a.Vi.Ai) be the MDG for mod- 
ule m^i. An system dependence graph (SDG) for V, de- 
noted by GsDG, is a directed graph (^^,V^,^^), where 
gp = Uf=iei is the set of entry vertices of the modules in 
V. V^ = ULil/^ U y/e U Vf^ U Vf^ U V^^ U V^o such that 
^i=iVi is the set of vertices; each represents a statement or 
control predicate in the modules in V; V^c is the set of join- 
point vertices] V?- or V? is the set of formal-in or form^al-out 
vertices] V^- or VJJ, is the set of actual-in or actual- out ver- 
tices. A"" = U^=iAi U A^. U APpo UA^UAPUAP^UAP such 
that Ui=iAi is the set of control and data dependence arcs 
in the MDGs of modules in P^; A^- or A^^ is the set of 
param^eter-in or param^eter-out arcs] A^ is a set of call arcs] 
A^ is the set of pointing arcs] A^ is the set of weaving arcs] 
A^ is a set of summary arcs. 

GsDG is a collection of MDGs; each represents a mainO 
method, a method of a class, a piece of advice or introduc- 
tion, or a method of an aspect. Gsdg also contains some 
additional arcs to represent direct or indirect dependences 
between a call and the called module and transitive inter- 
procedural data dependences. 

Gsdg uses join-point vertices to represent pointcuts in V. 
Gsdg also uses form^al-in and form^al-out vertices to rep- 
resent formal parameters in a module, and actual-in and 
actual- out vertices to represent actual parameters at each 
call site. In Gsdg, call arcs represent the calling and callee 
relationships between modules. Weaving arcs connect the 
MDG for a method to the MDG for its corresponding ad- 
vice; these arcs represent the relationships between advice 
and those methods that the advice may affect. Actual-in 
and formal-in vertices are connected by parameter-in arcs 
and formal-out and actual-out vertices are connected by 
parameter- out arcs to model the parameter passing between 
modules. Gsdg uses summary arcs to represent the transi- 
tive flow of dependences. 

[Example] Figure 4 shows the complete SDG for program 
in Figure 1, which was constructed by the algorithm de- 
scribed in Figure 5. 

3.5 The Algorithm for SDG Construction 

Our SDG construction algorithm for an aspect-oriented pro- 
gram V consists of four steps: (1) preprocessing each aspect 
and class; (2) building MDGs for modules; (3) connecting 
MDGs at callsites; (4) weaving MDGs at join points. 

Figure 5 shows our SDG construction algorithm BuildSDG. 
As input BuildSDG gets the control flow graph for each mod- 
ules in all aspects and classes of V, and as output BuildSDG 
returns the P's SDG. First, BuildSDG preprocesses each as- 




Figure 4: An SDG of the program in Figure 1. 



pect and class in V to get those kinds of information that 
are necessary for constructing the SDG (Unes 1-12). Sec- 
ond, BuildSDG builds the MDG for each piece of advice, 
introduction, and method in an aspect or class. It builds 
these MDGs in a bottom-up fashion according to the aspect 
and class hierarchies (lines 13-31). After that, BuildSDG 
calls Connect to connect these MDGs at call sites to form 
a partial SDG for V (line 32). Finally, BuildSDG builds 
the complete SDG for V by (1) calling Weaving () to weave 
the MDG for each piece of advice into the MDGs for its 
corresponding methods in the partial SDG, and (2) calling 
AddSummaryArcsO to compute summary arcs at call sites 
regarding both aspects and classes (lines 33-34); we can use 
an existing technique presented in [18] to implement the pro- 
cedure AddSummaryArcs . In the following, we describe our 
algorithm step by step. 

Stepl: Preprocessing Aspects and Classes. In this 
step, BuildSDG first identifies advice, introduction, and meth- 
ods that require new MDGs, and then computes the GREF 
and GMOD sets for each module. Finally, BuildSDG deter- 



mines the affected-method set for each pointcut. 

(1) Identifying Advice, Introduction, and Methods Requir- 
ing New MDGs. BuildSDG uses an existing algorithm [14] 
to identify methods in each class that require a new MDG. 
It builds on this idea to identify advice, introduction, and 
methods in each aspect that requires a new MDG. We de- 
scribe this identification process only for aspects here; for 
classes, one can refer to [14]. 

For an aspect a, BuildSDG calls a marking procedure to op- 
erate on a's call graph to identify the advice, introduction, 
and methods that require new MDGs. First, it marks the 
advice, introduction, and methods declared in a. Second, if 
a extends some base aspects^, it marks the advice, introduc- 
tion, and methods in the base aspects that can reach these 
marked advice, introduction, and methods by performing a 
backward traversal on a's call graph from these marked ad- 
vice, introduction, and methods. Finally, all marked advice. 



We can use a similar technique to handle the case that a is extended 
from a class or interface. 



algorithm BuildSDG 

input Control flow graphs (CFGs) of program P 
output System dependence graph (SDG) of P 
declare 

begin BuildSDG 

/* Step 1: Preprocessing the program V */ 
1] foreach class C 

2] Identify the methods that need new MDGs 
3] endfor 

4] foreach aspect A 

5] Identify the advice, introduction, and methods that 
need new MDGs 
endfor 
7] foreach module vn 

Compute GREF and GMOD sets for m 
9] endfor 
[10] foreach pointcut pc 
[11] Compute aff'ected-method set for pc 
[12] endfor 

/* Step 2: Build MDGs for methods in each class and 
advice, introduction, and m,ethods in each aspect */ 
[13] foreach class C 

[14] Construct an MDGs for each method in C 
[15] endfor 
[16] foreach aspect A 

17] foreach advice, introduction, or method m. declared in A 
18] Compute control dependences for m 

19] Compute data dependences for m 

20] Expend objects in m. 

21] Compute data dependences for objects 

22] endfor 
23] foreach advice, introduction, or method m 

in the base aspects 
24] if m. is "marked" then 

25] Copy old module dependence graph 

26] Adjust callsites 

27] else 

28] Reuse m's old module dependence graph 

29] endif 

30] endfor 
[31] endfor 

/* Step 3: Connecting MDGs at call sites */ 
[32] Connect 

/* Step 4- Weaving MDGs at pointcut sites */ 
[33] Weaving 
[34] AddSummaryArcsO 
end BuildSDG 



Figure 5: Algorithm for SDG construction. 



introduction, and methods require new IVEDGs. 

(2) Determine GREF and GMOD Sets for Each Module. 
BuildSDG uses a's call graph to compute the interface (i.e., 
two sets GREF and GMOD), for the advice, introduction, 
and methods that require new IVEDGs. For a piece of ad- 
vice, introduction, or method m, GREF(m) is the set of 
non-local variables (i.e., parameters, instance variable, or 
data members) to which m refers, and GMOD(m) is the set 
of non-local variables that m might modify. Using a tech- 
nique that is similar to the construction of a callsite or entry 
site for a method, which is described in Section 2.2, (1) a 
complete call site (i.e., call and actual parameter vertices) 
for a method call statement can be created, and (2) a com- 
plete entry site (i.e., entry and formal parameter vertices) 
for a piece of advice, introduction, or method m can be cre- 
ated based on the GREF and GMOD sets of m. GREF(m) 
and GMOD(m) can be determined by an existing data-flow 
analysis algorithm [12]. 

(3) Determine Affected- Method Sets for Each Pointcut. In 
this phase, BuildSDG calls PointcutAnalysisO to perform 



static analysis on each pointcut to determine the methods 
that the pointcut may affect. As input Point cut Analysis () 
gets a pointcut pc, and as output PointcutAnalysisO re- 
turns a set called affected-methods- set which records meth- 
ods that may be affected by pc. 

Step 2: Building MDGs for Modules. In this step, 
BuildSDG uses an existing algorithm [14] to construct an 
IMDG for each method in each class and uses a slightly mod- 
ified version of the algorithm to construct an IMDG for each 
piece of advice, introduction, and method in each aspect. 
We briefly describe the algorithm here; details can be found 
in [14]. 

BuildSDG constructs the module dependence graph for a 
piece of advice, introduction, or method m declared in a new 
aspect based on m's control flow graph. BuildSDG builds 
the control dependence graph for m using an existing algo- 
rithm [6], and builds the data dependence graph for m in 
three phases. First, BuildSDG preprocesses m using an al- 
gorithm that is a modified version of the usual data depen- 
dence graph construction algorithm [1]. Second, BuildSDG 
expands a vertex that references an object into the repre- 
sentations. Third, BuildSDG computes data dependences for 
data members of the objects. These three steps can handle 
objects at call sites, objects as parameters, and polymor- 
phic objects. In addition, BuildSDG constructs the mod- 
ule dependence graph for a piece of advice, introduction, or 
method m declared in a base aspect using a similar way as 
described in [14]. 

Step 3: Connecting MDGs at Call Sites. In this step, 
BuildSDG connects the IVEDGs created in Step 2 at call sites 
to form a partial SDG for an aspect-oriented program. At 
each call site, BuildSDG connects the IMDG for the called 
introduction or method to the IVEDG for the calling advice, 
introduction, or method using three types of arcs: (1) a call 
arc connects a call vertex to the entry vertex of a called in- 
troduction or method; (2) a parameter-in arc connects each 
actual-in vertex at the call site to the corresponding formal- 
in vertex; (3) a parameter-out arc connects each formal-out 
vertex to the corresponding actual-out vertex at the call site. 

At each pointcut site, BuildSDG connects the join-point ver- 
tex for a pointcut to the entry vertex of its corresponding 
advice using three types of arcs: (1) a pointing arc connects 
a join-point vertex to the entry vertex of its corresponding 
advice; (2) a parameter-in arc connects each actual-in vertex 
at the pointcut site to the corresponding formal-in vertex at 
advice site; (3) a parameter-out arc connects each formal- 
out vertex at the advice site to the corresponding actual- 
out vertex at pointcut site. IMoreover, if multiple pieces of 
advice apply to the same pointcut, BuildSDG connects the 
join-point vertex of the pointcut to the entry vertex of each 
piece of advice by pointing arcs respectively. In this case, 
we ignore the advice precedence because the connection is 
not related to the resolution order of the advice. 

Step 4: Weaving MDGs at Join Points. To form the 
complete SDG, we need to know some join points in the 
IMDGs for methods at which the IMDGs for methods and 
their corresponding advice can be woven in a natural way. 
As we discussed previously, since an aspect-oriented pro- 
gram is woven at some join points specified in pointcuts, we 
can use join-point vertices for weaving IMDGs for advice and 



Table 1: Parameters contributing to the SDG size. 



Parameters 


Meanings ot Parameters 


^vertex 


Largest number of statements in a single advice, 
introduction, or method 


'Jarc 


Largest number of arcs in a single advice, 
introduction, or method 


'Jparam 


Largest number of formal parameters for any 
advice, introduction, or method 


distant 


Largest number of instance variables in an 
aspect or class 


'Jcallsite 


Largest number of call sites in any advice, 
introduction, or method 


Jtree 


Depth of inheritance tree determining number 
of possible indirect call destinations 


^module 


Number of advice, introduction, and methods 



methods. The task for weaving the complete SDG consists 
of two phases: (1) weave the MDGs for advice in aspects 
into the MDGs for their corresponding methods in classes; 
(2) add summary arcs to form the final complete SDG. 

Weaving connects the entry vertex of each method's MDG 
in the partial SDG to the join-point vertex of a pointcut that 
refers to the method by a weaving arc. If the advice attached 
to the pointcut is a piece of around advice that contains 
a proceed clause, Weaving () connects the proceed call 
vertex to the entry vertex of the original method's MDG by a 
call arc to represent that the around advice may execute the 
proceed call, which leads to execute the original method 
under the join point declared by the pointcut. 

To model parameter passing between the method and its 
corresponding advice. Weaving () uses a similar technique 
as in phase (1). For each join-point vertex, actual-in and 
actual-out vertices are created for each parameter of the 
pointcut. For each entry vertex of the advice's MDG, formal- 
in and formal-out vertices are created for each formal pa- 
rameter in advice. Weaving () uses parameter-in arcs to 
connect the actual-in vertices to the formal-in vertices, and 
uses parameter-out arcs to connect formal-out vertices to 
the actual-out vertices between the pointcut and the advice. 
Weaving does this iteratively until all pieces of advice in 
all aspects have been processed. 

3.6 The Size of SDG 

The size of SDG is critical for applying it to the practi- 
cal development environment for aspect-oriented programs. 
Here we try to predict the size of SDG based on the work of 
Larsen and Harrold [13], who gave an estimate for the size 
of the SDG for object-oriented programs. 

In Aspect J, class declarations are like class declarations in 
Java except that they can also include pointcut declarations, 
and aspect declarations are like class declarations in Java 
except that they can also include pointcut, advice, and in- 
troduction declarations. As a result, we can apply Larsen 
and Harrold's approximation here to estimate the size of the 
SDG of an aspect-oriented program by regarding an aspect 
as a class-like unit and a piece of advice or introduction as a 
method-like unit. However, since our SDG is constructed for 
an aspect-oriented program, its size may be different than 
the SDG of an object-oriented program. 

Table 1 lists the parameters that contribute to the size of 
an SDG, denoted by Gsdg, for aspect-oriented programs. 
We give a bound on the number of parameters for any ad- 



vice, introduction, or method m^ denoted by Tparamirn)^ 
and use this bound to compute an upper bound on the size 
of a single advice, introduction, or method m^ denoted by 
Tsize{m). Based on Tsize{m) and ^module (number of ad- 
vice, introduction, and methods in an aspect-oriented pro- 
gram), we can compute the upper bound on the number of 
vertices in Gsdg including all aspects and classes, denoted 
by T size{GsDG) that contribute to the size of the SDG of 
the program. 

-I- Param\J^) ^ ^param \ ^instant] 
Tsize{m) = 0(7^;ertex+7cansite*(l+7ir'ee*(2*Tparam(m))) + 

2 * Tparam{m)); 
TsizeiGsDc) = 0{Tsize{m) * ^module)- 

From the above estimate, we can see that T sizeiGsDo) pro- 
vides only a rough upper bound on the number of vertices 
in an SDG. In practice an SDG may be considerably more 
space efficient. 



4. RELATED WORK 

We discuss related work in the area of developing depen- 
dence based representations (DBRs), a general class of pro- 
gram representations that includes SDGs. 

DBRs have been primarily studied for procedural programs 
to support compiler optimization and develop software engi- 
neering tools. Ferrante et al. [6] use the program dependence 
graph (PDG) to explicitly represent control and data depen- 
dences in a procedural program. The envisioned uses are 
compiler optimizations and program slicing [20]. Horwitz 
et al. [7] extend the PDG to the system dependence graph 
(Horwitz-Reps-Binkley SDG for short) to represent a proce- 
dural program with multiple procedures. Cheng [5] presents 
a process dependence net which is the generalization of the 
PDG to represent program dependences in a concurrent pro- 
cedural program. The goal is to support the development of 
concurrent programs. Krinke [10] uses a threaded program 
dependence graph that can present interference dependences 
in a concurrent program; the intended application is pro- 
gram slicing. Although these DBRs can effectively represent 
the features in procedural programs, they were not designed 
to represent object-oriented and aspect-oriented constructs. 

DBRs have been applied to represent object-oriented pro- 
grams recently. Larsen and Harrold [13] present a new 
system dependence graph (Larsen-Harrold SDG), that ex- 
tends the Horwitz-Reps-Binkley SDG, to represent object- 
oriented programs for program slicing. Their SDG can rep- 
resent many object-oriented features such as classes and 
objects, inheritance, polymorphism, and dynamic binding. 
Liang and Harrold [14] further extend the Larsen-Harrold 
SDG to represent object parameters, polymorphic objects, 
and class libraries. Kovacs et al. [11] extends the Larsen- 
Harrold SDG to represent Java programs. In addition to 
general object-oriented features, their SDG can represent 
some Java-specific features such as static variables, inter- 
faces, and multiple packages. On the other hand, McGre- 
gor et al. [15] take a different way to develop a DBR called 
object-oriented program dependency graph (OPDG) for object- 
oriented programs. The OPDG is an extension of the PDG 
[6] and can be used as a basis for computing layered static 
slices for object-oriented programs. Chen et al. [4] also 
extends the PDG [6] to a object-oriented dependency 



for representing object-oriented programs. These DBRs can 
effectively represent object-oriented programs, but are not 
designed to represent specific aspect-oriented features such 
as join points, advice, introduction, aspects, aspects, and 
aspect inheritance in aspect-oriented programs. 

Recently, Zhao [21] presents a DBR called an aspect- oriented 
system dependence graph (ASDG) for slicing aspect-oriented 
programs. The ASDG consists of an SDG for the non-aspect 
code, a group of dependence graphs for the aspect code, and 
some additional vertices and arcs to represent dependences 
between aspects and classes. However, Zhao dose not give 
a concrete algorithm for constructing the ASDG, therefore 
how to represent aspect weaving in an SDG is not clear. We 
see our work differing from Zhao's in several ways. First, 
we give a concrete algorithm for constructing an SDG for 
aspect-oriented programs. Our algorithm gives an efficient 
way to weave dependence graphs for base and aspect code 
and to model the parameter passing between pointcuts and 
their corresponding advice. Second, in contrast to Zhao's 
approach (which requires the creation of some extra weav- 
ing vertices to facility the weaving of dependence graphs 
for base and aspect code), we use pointcuts as join points 
directly, then use pointing and weaving arcs to represent 
aspect weaving. This approach reflects the actions of an 
aspect weaver, which weaves the aspect code into the base 
code at join points. Third, our SDG can represent many 
more aspect-oriented constructs. These constructs include 
around advice, advice precedence, introduction scope, and 
aspect inheritance. 

5. CONCLUDING REMARKS 

In this paper we extend previous system dependence graphs 
(SDGs) to represent aspect-oriented programs and present 
an algorithm for constructing SDGs. Our SDG construc- 
tion algorithm consists of several steps. It first constructs 
a module dependence graph (MDG) for each piece of ad- 
vice, introduction, and method in each aspect and class. It 
then uses existing techniques for object-oriented programs 
to connect these MDGs at call sites to form a partial SDG. 
Finally, our algorithm weaves the MDG for each piece of ad- 
vice into the partial SDG for those methods whose behavior 
may be affected by the advice. The result is the complete 
SDG. Our SDGs capture the additional structure present in 
many aspect-oriented features such as join points, advice, 
introduction, aspects, and aspect inheritance, and various 
types of interactions between aspects and classes. They also 
correctly reflect the semantics of aspect-oriented concepts 
such as advice precedence, introduction scope, and aspect 
weaving. SDGs therefore provide a solid foundation for the 
further analysis of aspect-oriented programs. 
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